FIG. 1 illustrates a prior art enterprise satellite network. An enterprise satellite network 100 includes a head network 102 and a remote network 124. The head network 102 and the remote network 124 interface to one another by using an enterprise router 104 interfacing with a satellite gateway 106 that includes a satellite hub 108, a satellite 110 providing a space link 112 to link the satellite hub 108 with a Very Small Aperture Terminal (VSAT) 122, and a remote router 126. As such, a remote network 124 provided by the remote router 126 interfaces a remote node 128 including a remote device 130 to the head network 102. Typically, a satellite hub 108 interfaces the enterprise router 104 to the remote router 126 using the space link 112 provided by the satellite 110. The space link 112 is accessed by the satellite hub 108 at the head network 102 and by the VSAT terminal 122 at the remote networks 124 to form the enterprise network 100. Typically, the Enterprise Router 104 and the satellite gateway 106 are deployed at the head office of the enterprise. The remote router 126 and the VSAT 122 are deployed at a remote site or office of the enterprise.
Typically, the enterprise network 100 propagates IP routes using a standard routing protocol 140 between the enterprise router 104 and the satellite hub 108, a proprietary routing protocol 142 between the satellite hub 108 and the VSAT 122 over the space link 112, and a standard routing protocol 144 between the VSAT 122 and the remote router 126. Routing within a remote network 124 may be provided by a standard routing protocol 146.
The proprietary routing protocol 142 is used over the space link 112. Use of the proprietary routing protocol 142 has several limitations:
proprietary routing protocol 142 limits propagation of routes within the enterprise network 100 to options supported by the proprietary routing protocol 142;
its impractical to develop a proprietary routing protocol 142 to carry all possible routing options that an enterprise may wish to exchange;
the proprietary routing protocol 142 needs significant upkeep to match the constantly changing face of enterprise network;
developing the proprietary protocol stack 142 is an expensive and often buggy experience, whereas standard routing protocols have been battle hardened by years of use;
adds a burden to the enterprise personnel of learning how to utilize the proprietary routing protocol 142, and
provides dissonance between the standard routing protocols 140 and 144, and the proprietary routing protocol 142.